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SMTP 521 Reply Code 


Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] 
reply code, 521, which one may use to indicate that an Internet host 


does not accept incoming mail. 


1. Motivations 


Hosts on the Internet have shifted from large, 


general-purpose hosts 


to smaller, more specialized hosts. 


There is an increasing number of 


hosts which are dedicated to specific tasks, 


such as serving NTP or 


DNS. These dedicated hosts frequently do not provide mail service. 


Usually, these mailless hosts do not run an SMTP server. 
Unfortunately, users will occasionally misaddress mail to these 
hosts. Regular SMTP clients attempting to deliver this misaddressed 
mail must treat the lack of an SMTP server on the host as a temporary 
error. They must queue the mail for later delivery, should an SMTP 
server be started at a later time. 


This causes the mail to remain queued for days, until it is returned 


with what is usually a confusing error message. 
2. Two complementary solutions 
Two complementary solutions MAY be implemented to deal with this 
issue. The first one is to use MX relays to bounce misaddressed 


mails. The second one is to implement a minimal smtp server on the 
mailless host to bounce all mails. 


The choice between the two solutions is site dependent. 
Durand & Dupont 


Experimental [Page 1] 


RFC 1846 SMTP 521 Reply Code September 1995 


3. The MX relays solution 


MX relays may be used to indicate SMTP clients that an Internet host 
does not accept mail. 


During the SMTP dialog, these MX relays MAY bounce any message 
destinated to this particular host with an SMTP 521 reply code. 
SMTP dialog example: 


—--> 220 relay.imag.fr ready 


<--- HELO client.inria.fr 

-—--> 250 relay.imag.fr Hello client.inria.fr 

<--- MAIL FROM: <userl@client.inria.fr> 

---> 250 <userl@client.inria.fr>... Sender Ok 
<--- RCPT TO: <user2@nomail.imag.fr> 

---> 521 nomail.imag.fr does not accept mail 

<--- QUIT 


---> 221 relay.imag.fr closing connection 


If an MX relay of precedence n for a mailless host bounces mails on 
its behalf, then any other MX relay of precedence lower than n for 
this mailless host SHOULD do the same. 


4. The SMTP server solution 
4.1 521 greeting 


A host may indicate that it does not accept mail by sending an 
initial 521 "Host does not accept mail" reply to an incoming SMTP 
connection. The official name of the server host or its IP address 
MUST be sent as the first word following the reply code. 


For example: 521 canon.inria.fr does not accept mail 
4.2 SMTP dialog 


After issuing the initial 521 reply, the server host MUST do one of 
the following two options: 


a) Close the SMTP connection. 

b) Read commands, issuing 521 replies to all commands except QUIT. 
If the SMTP client does not issue the QUIT command after a 
reasonable time, the SMTP server MUST time out and close the 
connection. A suggested time-out value is 5 minutes. 
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DISCUSSION: 


When an SMTP server closes the connection immediatly after issuing 
the initial 521 reply, some existing SMTP clients treat the 
condition as a transient error and requeue the mail for later 
delivery. If the SMTP server leaves the connection open, those 
clients immediately send the QUIT command and return the mail. 


4.3 MX 


A host which sends a 521 greeting message MUST NOT be listed as an MX 
record for any domain. 


4.4 Postmaster 


An SMTP server which sends a 521 greeting message IS NOT subject to 
the postmaster requirement of STD 3, RFC 1123 ([2]). 


DISCUSSION: 


Postmaster exists so you can report mail errors. A host that doesn’t 
support mail doesn’t need a Postmaster. 


5. SMTP client behavior 


If an SMTP client encounters a host in an MX record that issues a 521 
greeting message, it must do one of the following two options: 


a) Attempt to deliver it to a different MX host for that domain. 
b) Return the mail with an appropriate non-delivery report. 


If an SMTP client encounters a 521 reply code in any other part of 
the SMTP dialog, it MUST return the mail with an appropriate non- 
delivery report. 


6. Security Considerations 


Not running any SMTP server, or running an SMTP server which simply 
emits fixed strings in response to incoming connection should provide 
significantly fewer opportunities for security problems than running 
a complete SMTP implementation. 
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8. Expericences 


People implementing this reply code are suggested to send a message 
to mailext@list.cren.net to report their experience. 
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